EC/CRMの自社サービス「prismatix」開発チームのプロジェクトマネージャーになって最初にやったことn連発

4ヶ月前に言ってたことダイジェスト

Dev PjMになって最初の頃、こんな話を書いていました。

prismatixの開発者から開発チームのプロジェクトマネージャーにクラスチェンジした話 | DevelopersIO

マネジメントの姿勢

そこで、私は 指揮者(Conductor) として振るまおうと決意しました。

何をしたいのか

Devチームを中心として系が回るようにする

ことを実現したいと思っています。

もう少しわかり易い言葉でいうと、「prismatixというサービスの 開発 を通じて、顧客およびチームに 価値を届け続けている 状態を作る」のが目的になります。

どうしていくのか

Devチームもハッピー、みんなもハッピー な状態に向けて、色々動いていこうと思っています。

それを踏まえて

• チーム間に落ちる球を拾いまくってました
• みんなが動きやすいような仕組みを作っていました
  • ただ、まだまだ途上なので継続して改善していきます

やったことn連発

これまでやったことの中で、公開できる情報/公開できない情報があります ^*1が、なるべく紹介していきます(順不同)。

1. 1on1

• 現状把握のため各所と会話した
  • Devの各サブチームリーダー ^*2
  • 運用を行うKibanチームのマネージャ、およびリーダー
  • 顧客フロント(PM) ^*3のマネージャ
  • プロダクトオーナー(PO)
  • 部内の情シス ^*4
  • ...
• 課題とか問題感、考えていること、思いなどを知れた
  • 理解しようとして、理解しきれてないこともあるとは思うけど

2. タスク流れ整理

• プロダクトバックログ(PBL)を導入
  • POが主導
  • タスクが優先順位たついた状態で「カンバン」として見えるように
• 差し込みタスクを最小限にする
  • 意思決定にマネジメントも入るように調整
• チーム連携が必要ならその調整も行う
  • prismatix事業部の外部の人も必要なら巻き込み

3. 情報同期のタイミングを増やす

• Dev開発状況共有開始
  • Devチームメンバーに対して、各チームでやっていることを週次で共有する
• Kibanとのウィークリーミーティング開始
  • 運用に関する改善点や課題などを週次で共有する
• 各チームでデイリーミーティング開始
  • リモートだからこそ「デイリースクラム」のような数分のミーティングを毎日行い個々のチームメンバーで情報を日次で共有する
• プロダクト報告会開始
  • Dev各チーム、PM、Kiban、情シスなどがやっていることを定期的に全体に共有する

4. チーム整理

• 「チーム」として最低の大きさに再編成
  • これまではそれぞれのチームが2名程度の「チーム」というにはあまりにも小さい単位だった
  • 関係の深い機能を一つのチームにすることで、マネジメントコストを下げる
  • コミュニケーションの活性化も狙いの一つにする
• 再編成されたチーム
  • 「リフォームの匠」チーム
    • プロダクトが生まれて数年経ち、溜まってしまった技術的課題を改善するメンバーを集める
    • 孤独になりがちな改善作業を一人旅にならないようにケアする目的
    • アーキテクト、QA(品質保証)の機能も持たせる
  • 注文・決済チーム
    • 関連の深い機能追加・変更を円滑に回せるようにするのが目的
    • 業務ドメイン知識が複雑なので、複数人で議論がしやすくなることも期待
  • 検索・保守チーム
    • 保守フェーズに入った機能担当と事実上保守状態の機能担当を統合
    • 日々の情報共有や気軽なレビュー依頼などをしやすくする目的

5. チーム開発勉強会(継続中)

• チームで開発するとはどういうことなのか、アジャイルとはなにか、というような勉強会を開催
• スピーカーはCX事業部内製化支援チームなど、他部署にも協力を依頼
  1. 阿部信介さん: 「アジャイル」とはなにか
  2. 藤村新さん: アジャイル推進時の苦労話
  3. 私: 理想の開発について ^*5
• 今後も別のネタで継続するつもり

6. アラート対応フロー改善

• Sentry、datadogなどのSaaSで検知したアラートの対応フローを整理
  • アラートのトリアージから担当部署へのエスカレーション条件を明記
• アラート対応マニュアル改善
  • 初手のトリアージをSentryのメッセージだけで判断できるように記載を改善
  • 対応が必要なアラートについて、エスカレーション先および条件をわかりやすくする
    • 「頻発していたら」のような曖昧な条件をなくすため
• それらをマニュアルの書き方にもフィードバックして反映

7. リリースノート改善(継続中)

• マイクロサービスコンポーネント(MSC)のリリースノートを、フロント開発者 ^*6が理解しやすい記載にする
  • バグなら修正前後でどう変わったか
  • 機能追加なら何を追加したのか関連ドキュメントへのリンクを併記、など
• 「リリースノート」のレビューがそもそも行われていなかったので、レビューするタイミングを追加
  • 具体的には、リリースノートの記載のもとになるPull Request(PR)に書いて、レビューするように
• リリースノートの書き方マニュアルも改善
• PMなどフロントに近いメンバーによるレビュー的なものを今後入れていきたい
  • 頻度が高いと回らないのでタイミングは要検討

8. リリースプロセス再検討(継続中)

• 多くの顧客に、シングルテナントで提供するAPIプラットフォームとして、あるべきリリースやデプロイの形を再検討
  • プロダクトが生まれて数年経っていて、なぁなぁでやっていて問題となっていた箇所などを洗い出す
    • リリースサイクル
    • リリース物の範囲
    • 作業のやりかた
    • ブランチ戦略
    • 後方互換性維持
    • そもそもの開発の進め方、など
• 「リフォームの匠」チーム主導
  • Kiban/PMも今後巻き込み予定

9. ログ改善(継続中)

• たまに発生するログ落ちをなるべく起こさないようにログアーキテクチャ刷新
• そもそもログの量を減らすのもやっていきたい
  • トレースログみたいなの無くして意味のあるログに

10. 大型リリース実施

• 決済代行サービス各社の 3Dセキュア 2.0 への切り替えへの対応
• リリースに伴いKibanとの連携ドキュメントを改善
  • 漏れ、誤りを最小限にするため
    • テンプレートに反映

11. デプロイ資料改善(継続中)

• リリースしたMSCを顧客環境にデプロイする際に必要なインフラや環境変数などの情報をKibanに連携している
• Kiban作業で必要な情報が漏れなく伝わるよう情報を整理
• 実際の記載内容を直していくのは継続中

12. 足回り改善(継続中)

• 技術的負債の返済やセキュリティなど
  • ライブラリ・ツール
    • Spring Boot バージョンアップ
    • Gradle バージョンアップ
  • セキュリティ
    • Dockerベースイメージ変更
    • 各種CVE関連の対応
      • Tomcatなど
  • ECRイメージサイズ300MB削減
• まだまだ色々あるので、継続して対応する

13. 入場フローおよびオンボーディング改善(継続中)

• 関係各所と新メンバー入場時のフローとオンボーディング資料を整理
  • 全体と各チームでやるべきことの明確化
• 新規入場者がすんなり業務に入れるように引き続き活動する
  • クラスメソッドとしても、新メンバーが初日から最高のパフォーマンスを出せるように改善施策を進めている

14. チーム体制ドキュメント改善

• 誰がどのチームで、どこのSlackのチャンネルをつかっているか、チームへの連絡窓口は何かを一覧化
  • 口伝で伝えていた内容を明記し、継続メンテを行うようにする

15. 注文・決済チーム開発サポート(継続)

• PjMになる前にいた「注文」チームの知識・スキルをメンバーに引き継ぎ中
  • 注文機能の仕様相談やタスクの順番などについてアドバイス
  • アラート発生時のログ調査、仕様問い合わせなどでアドバイス
• 引き続き仕様面や進め方でサポート継続
  • 4Qくらいである程度離れられたら、くらいのゆるい目標

16. 開発環境不要リソース整理(継続中)

• 社内検証用のAWSアカウントの使用していないリソースを停止したり削除したり
  • EC2インスタンス
  • EBS
  • Security Group
  • ECSクラスタ、など
• 無駄なコストを削減する

17. Kibanチームへ依頼する作業の手順書見直し

• 当初想定していない箇所で手順が止まると、ログを履き続けてCloudwatch Logsの料金が上がる問題があった
  • Kibanチームと協力してどうあるべきか議論
• まず手順の流れがわかりやすくなるように、手順を図にしてもらう
  • その上で同期ポイントを明確にして「エラー」が発生しないよう手順を見直してもらった

18. オフショア終了

• 一部のMSCチームのコーディングタスクをオフショアに出していた
  • コードがコントロールできなくなりかけていた
    • どこに何が書いてあるか把握しきれていない、など
  • こちらが休みでもオフショア先は休みでないため、「仕事のための仕事」が発生していた
    • 結果、レビューがされないで「不良在庫」となるPRが増えていた
• タスク管理、コードのコントロールにかかるコストを下げるためにオフショアをやめた
  • 設計とコードを自分たちで全部やる方式に戻す
  • 不良在庫をなくす
• チーム内にコードの知見が貯まるようにしたい
  • ただし、徐々に効果が現れるものなので今後に期待

19. 顧客本番環境デプロイにDev立ち会い体制づくり(継続中)

• これまでは顧客本番環境へのデプロイはKibanチームにおまかせ状態だった
  • 何かあったらDevを呼び出すやりかた
  • 深夜に呼び出して本当に対応してくれるのかという不安があった
• 今後はDevチームも立ち会いする体制を作っていく
  • Kibanチームがデプロイする際、何かあったら即対応できるようにするため
  • ただし、MSCごとにログ調査できる人が限られてしまっている状況は今後改善していかないといけない
• 何かあったときだけではなく、手順のクロスチェッカーとしての役割も持たせたい
  • 今後期待値をKibanチームと擦り合わせていく

20、21、22... (細かいのたくさん)

• 日々の球拾い
  • Slackで見かけたお困りの解決に向けた協力など
• Devチームという枠にとどまらずチーム全体に対して
  • みんながなるべくハッピーになるように

これまでのふりかえり

• マイクロマネジメントが多い
  • チームメンバーに任せて動けるようにしていきたい
• 俯瞰した視点が自分に足りない
  • 高いレベルを意識して考える時間を作りたい

今後やりたいこと

順不同

理想の開発像の提示

• 自分の中でまだもやもやとしてまとまっていない
• 何度か出していきながら自分でも明確化させていく

アジャイルイベント導入

• スクラム等のアジャイルプロセスのイベントを、まず教科書どおりにやってみる
• 何をやるのかを再定義して進めたい
  • ふりかえり
  • スプリントプランニング
  • etc...
• DevチームだけでなくPMやKibanチームも横断でやりたい
  • 対話を続けていく

プロジェクト計画改善

• 何をやるのか、どうやるのか、いつやるのか、いつ終わりそうなのかを明確に
  • タスクばらしと見積、そしてベロシティ計測からバーンダウンチャートを元に完了見込み時期を予測する、みたいな
• まずはタスクをバラすところから

リリース会開催

• prismatixチーム全体として「リリース」を行いたい
  • 今はDevチームだけのリリースみたいになっている
  • 「顧客に届ける」ための準備をDevだけでなくみんなでやりたい

フロント巻き込み

• 顧客への価値を見据えて、どうやるといいんだっけを考え直す
  • そのためにフロントとも、もっと関わる
• こういった動きをどうやっていくか検討

開発パフォーマンス改善

• Devだけではなくprismatixチーム全体として顧客へ届ける価値を最大化したい
  • その中で品質や開発プロセス等を見直していきたい
    • 設計、レビュー、テストなど
  • 教育的なものも含みます
    • 若手・中堅問わず

監視改善

• Dev/Kibanの垣根を超え「何を監視すべきか」を見直したい
  • 顧客に価値のある「監視」とは

最後に

Devもハッピー、周りもハッピー

を目指して引き続き活動していきます。

脚注